Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.93-04-15 < prev next >

Wrap

Text File | 1993-06-05 | 10.7 KB | 330 lines

IETF STEERING GROUP (IESG) REPORT FROM THE IETF MEETING April 15th, 1993 Reported by: Greg Vaudreuil, IESG Secretary This report contains IESG meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. For more information please contact the IESG Secretary. iesg-secretary@cnri.reston.va.us. ATTENDEES --------- Bradner, Scott / Harvard Chapin, Lyman / BBN Coya, Steve / CNRI Crocker, Dave / SGI Crocker, Steve / TIS Gross, Phillip / ANS Hinden, Robert / SUN Kahle, Brewster / WAIS Knowles, Stev / FTP Software Piscitello, Dave/ Bellcore Rose, Marshall / DBC Vaudreuil, Greg / CNRI Regrets Huizer, Erik / SURFnet Mankin, Allison / Locus Reynolds, Joyce / ISI Stockman, Bernhard / SUNET/NORDUnet IAB Liaison Christian Huitema / INRIA AGENDA ------ 1. Administrivia o Roll Call o Bash the Agenda o Approval of minutes - April 8th 2. Protocol Actions o X.400 Routing Coordination o Distributed Authentication Security Service 3. Working Group Actions o Modem Management (modemmgt) o Character MIB (charmib) o DECnet Phase IV MIB (decnetiv) o AToM MIB (atommib) 4. Tasked Items o RIP A/S o Revised IPLPDN Working Group Charter 5. Management Issues o Alignment of the Working Groups o Informal operations review of Internet Drafts o Compressing TCP/IP Headers o DHC -- Status check o Requirements for Draft Standard - Implementation of the IESG policy MINUTES ------- 1) Administrivia o Approval of the Minutes With corrections, the minutes of the April 8th teleconference were approved. o Next Meeting In an effort to reduce the time demands on IESG members, the next meeting was scheduled for April 29th. 2) Protocol Actions o X.400 Routing Coordination In the absence of Eric Huizer, this document was not reviewed. o Distributed Authentication Security Service The DASS work was submitted by the CAT work for consideration as an Experimental Protocol. This effort was initially intended to be on the standards track but the group has requested Experimental because the development effort lost funding. This work was originally developed within DEC and it is unclear whether there are still intellectual property claims on this work. Efforts were initiated to secure a letter of release but the current status is unknown. As an experimental protocol a formal release is not needed, but the RFC should indicate any Intellectual Property rights claims on the content. ACTION: Coya -- Inquire with Jon Postel and Vint Cerf about the current requirements for the intellectual property rights declaration on non-standards track RFCs. ACTION: SCrocker -- Clarify with the authors of the DASS document the status of any intellectual property right claims. 3) Working Group Actions o Modem Management (modemmgt) The IESG reviewed and approved the Modem Management Working Group charter. This group met at the Columbus IETF meeting as a BOF. The group intends to maintain liaisons with several external organizations but has been discouraged from operating a lock-step manner. ACTION: Vaudreuil -- Announce the formation of the Modem Management Working Group to the IETF list. o Character MIB The new Character MIB Working Group charter was approved. This Working Group was rechartered to review the current standardization status of the several character MIBs. ACTION: Vaudreuil -- Announce the re-formation of the Character MIB Working Group. o DECNet Phase IV MIB The new DECNet Phase IV MIB Working Group charter was approved. This Working Group was rechartered to review the current standardization status of the several character MIBs. ACTION: Vaudreuil -- Announce the re-formation of the DECNet Phase IV MIB Working Group. o ATM MIB (atommib) The IESG approved the charter for the ATM MIB Working Group. This group is expected to be long lived given the evolving ATM standards the many layers of the ATM protocol. ACTION: Vaudreuil -- Announce the formation of the ATM MIB Working Group. The ATM MIB is one of several MIBs based on the aging Interfaces group. The Interfaces group was written with a bit of a simplistic model which does not work well with virtual circuit and tunneling technologies. A new Working Group is being formed to revisit the Interfaces group. The work of the ATM MIB group will be aligned with the resulting new model and MIB. 4) Tasked Items o RIP A/S No progress to report. o IPLPDN Charter. Discussions on the future scope of the IPLPDN Working Group are continuing. 5) Management Issues o Alignment of Working Groups Due to limited time in the IESG meeting, a review will be conducted by email for approval of the current alignment of Working Groups into the re-staffed IESG areas. ACTION: Vaudreuil -- Send out the current Working Group summary to confirm the current Working Group and Area alignments. o Operational Requirements Review of Internet Drafts An informal review of all Internet Draft is being conducted in the Operations Area. This effort focus on evaluating the operational impact of new proposals and feeding comments back to the authors. This function is separate from but is expected to be included into the scope of the Operations Area Directorate when finalized. This review is being done on an experimental basis to gauge whether the comprehensive review of proposals will have a benefits worth the effort. Suggestions were made to publish a list of operational criteria by which the proposals will be measured. Other ideas included a dedicated section in the RFCs similar to the security considerations section identifying possible operational impacts. The IESG has discussed several "considerations" sections in the past and discussion of the proposed "operational considerations" section was deferred until a list of all such sections discussed by the IESG could be gathered. ACTION: Vaudreuil -- Get all the IESG discussions on various "considerations" sections together for review at a future teleconference. o Compressing IP headers Allison Mankin was not present to give a status update. o Dynamic Host Configuration The Working Group has worked out a few bugs and the area director has pressed the group to get the current version out as a Proposed Standard. The editing cycle is continuing too long. Revisions are possible as the proposals go to draft standard. o Requirements for Draft Standard The IESG continued a discussion from the last meeting to refine the requirements for a protocol to be advanced to Draft Standard. After a bit of discussion, the following requirements was made. POSITION: ALL protocols being considered for Draft Standard status must have at least two implementations, each of which supports all features and options and between which all features and options have been tested. Features and options which have been speicified for future use but which have not been tested must be removed from the specification prior to advancement to Draft Standard. The IESG earlier adopted a position that all protocols eligible for advancement to Draft Standard be presented to an IETF plenary. With the growing number of protocols, the growing size of the IETF including mailing list only participants, the reduced frequency of meetings, and the use of the last call procedure, this requirement has been lifted. POSITION: Unless requested by an Area Director, it is no longer expected that a plenary presentation be made for each protocol under consideration for Draft Standard. Currently it is possible to standardize multiple competing protocols. The IESG discussed the cost to vendors and providers who must support each of the protocols and considered a proposal that only one protocol for a given function be allowed to reach Standard status. The IESG did not agree on this idea but did affirm that the goal is to have one protocol per function. It may be reasonable to have multiple protocols that perform a function such as a generalized protocol with many features and a limited protocol optimized for a particular situation. o Wide Area Routing with RIP This may be a topic for the routing work the IPLPDN Working Group was originally chartered to do. The Internet Area agreed to review the protocol analysis for assignment. o Frame Relay Service MIB WG The Frame Relay Service MIB effort will be defining managed objects for service management, rather than device management--a new area for IETF standardization. The IESG briefly discussed the proposed working group scope and management along with the Competing technical approaches that were being pursued. There was also discussion on which area this effort should be placed under, who should be named chair. The IESG agreed that the handling, to date, was acceptable, and further agreed that this effort should be placed in the Network Management area, with a neutral party named as chair. Appendix -- Summary of Action Items Assigned ACTION: Coya -- Inquire with Jon Postel and Vint Cerf about the current requirements for the intellectual property rights declaration on non-standards track RFCs. ACTION: SCrocker -- Clarify with the authors of the DASS document the status of any intellectual property right claims. ACTION: Vaudreuil -- Announce the formation of the Modem Management Working Group to the IETF list. ACTION: Vaudreuil -- Announce the re-formation of the Character MIB Working Group. ACTION: Vaudreuil -- Announce the re-formation of the DECNet Phase IV MIB Working Group. ACTION: Vaudreuil -- Announce the formation of the ATM MIB Working Group. ACTION: Vaudreuil -- Send out the current Working Group summary to confirm the current Working Group and Area alignments. ACTION: Vaudreuil -- Get all the IESG discussions on various "considerations" sections together for review at a future teleconference. Appendix -- Summary of Positions Taken POSITION: ALL protocols being considered for Draft Standard status must have at least two implementations, each of which supports all features and options and between which all features and options have been tested. Features and options which have been speicified for future use but which have not been tested must be removed from the specification prior to advancement to Draft Standard. POSITION: Unless requested by an Area Director, it is no longer expected that a plenary presentation be made for each protocol under consideration for Draft Standard.